Distributed systems for stormwater monitoring and reporting

ABSTRACT

Distributed systems and methods for the automatic monitoring and reporting of data relating to the chemistry and flow of stormwater (i.e. stormwater data) are presented. Multiple fluid sensor devices are exposed to stormwater via positioning the sensor devices in locations of interest. The sensor devices are arranged in self-healing mesh networks. The sensor devices are enabled to acquire stormwater data indicating various fluid properties that are desired to be monitored. A sensor device is further enabled to transmit its acquired stormwater data, either directly or indirectly, to one or more remote computing devices that is hosting a stormwater monitoring application (SMA). The SMA is enabled to process and analyze the stormwater data. The SMA generates measurements and reports based on the processed and analyzed stormwater data.

CROSS REFERENCE TO RELATED APPLICATIONS

The application claims priority to U.S. Nonprovisional patentapplication Ser. No. 15/480,084, filed on Apr. 5, 2017, entitledDISTRIBUTED SYSTEMS FOR STORMWATER MONITORING AND REPORTING, theentirety of the contents herein incorporated.

The application claims priority to U.S. Provisional Patent ApplicationNo. 62/319,084, filed on Apr. 6, 2016, entitled STORMWATER MONITORINGSYSTEM, the entirety of the contents herein incorporated.

The application also claims priority to U.S. Provisional PatentApplication No. 62/321,011, filed on Apr. 11, 2016, entitled SCREENDESIGN, FLOW CHANNEL, SENSOR ARRAY FOR FLOW-THROUGH STORMWATERMONITORING HARDWARE, the entirety of the contents herein incorporated.

BACKGROUND

Stormwater drainage systems (e.g. storm drains and sewers) are employedto redirect excess rain and ground water from impervious surfacesthrough a network of flow paths and/or flow channels. Such flow pathsand/or channels are typically constructed via cavities, flow paths, orflow channels within pipes, tunnels, gutter, and the like. Thestormwater may be redirected into nearby rivers, streams, or otherwaterways via such stormwater drainage systems. Due to the passivenature of collecting and transporting water in pipes, tunnels, andgutters, stormwater drainage systems are susceptible to clogging viadebris and/or sediments. Furthermore, such passive systems may introducethe debris, sediments, or even contaminants into rivers, streams, andother waterways. Accordingly, it is desirous to monitor variousproperties of stormwater flowing through stormwater drainage systems. Itis for these and other concerns that the following disclosure isprovided.

SUMMARY

Embodiments of the present invention are directed towards methods andsystems for automatically monitoring and reporting on stormwater. Onsuch exemplary embodiment includes providing, to a data-collectiondevice, a configuration for the data-collection device and for each ofmultiple stormwater sensor nodes or sensor devices. The data-collectiondevice may be a controller node. The configuration for thedata-collection device and/or a configuration for each of the sensordevices may be a transmitter-receiver pair. For instance, theconfiguration for the data-collection device may include at least adata-transmission frequency and a defined data-transmission channel. Theconfiguration for the sensor devices may include a data-acquisitionfrequency and another data-transmission frequency. The data-transmissionfrequency for the sensor devices and the data-collection devices may beequivalent, similar, or dissimilar.

The data-collection device is employed to provide the stormwater sensordevices at least a portion of the configurations. Each of the stormwatersensor devices is employed to iteratively acquire stormwater data.Stormwater data may be acquired at a particular stormwater sensor at arate that is based on the data-acquisition rate for the correspondingstormwater sensor devices. The stormwater sensor devices are employed toprovide the stormwater data to the data-collection device. For instance,the stormwater sensor device may provide the stormwater data to thedata-collection device at a rate based on the data-transmission rate forthe stormwater sensor device.

The data-collection device is employed to aggregate the stormwater datathat is acquired form the stormwater sensor devices. The data-collectiondevice is employed to periodically provide a user-computing device theaggregated stormwater data at a rate based on the data-transmission ratefor the data-collection device. The user computer may be running and/orhosting a stormwater monitoring application (SMA) that is employed toreceive the stormwater data and generate one or more stormwater reportsor visualizations based on the measured stormwater data. For instance,the stormwater measurement may be a site-level stormwater measurement. Adisplay device of the user-computing device may provide a visualization(e.g. a plot, graph, chart, or the like) of the stormwater measurements.

In various embodiments, the method further includes receiving ageo-location and a sensor identifier for each of the stormwater sensordevices. A sensor identifier may include a unique code, number, string,or other identifying nomenclature for the sensor device. Thegeo-location and the sensor identifier are associated and stored. Forinstance, the association between the geo-location and sensor identifiermay be stored in a registration for the sensor device.

The user-computing device may be employed to generate a report based onthe stormwater measurements. Furthermore, the user-computing device maybe employed to provide the report to a user. The stormwater sensordevices may include various sensors, such as but not limited to fluidflow rate sensors, fluid pH-level sensors, fluid temperature sensors, orthe like.

In some non-limiting embodiments, the stormwater sensor devices arestormwater sensor nodes that are configured and/or arranged in a meshnetwork. The mesh network may be a self-healing mesh network. Thedata-collection device may be a controller node the mesh network. Thestormwater sensor device may be distributed across a portion of astormwater drainage system. The method may employ the user-computingdevice to determine a Gauckler-Manning coefficient associated with thestormwater drainage system. The determination of the coefficient may bebased on the stormwater data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary embodiment of a distributed systemenabled to simultaneously and actively monitor stormwater acrossmultiple remote locations, acquire, aggregate, and analyze stormwaterdata from the multiple locations, and generate stormwater reports andnotifications based on the stormwater data analysis that is consistentwith the various embodiments discussed herein.

FIG. 2A schematically illustrates an exemplary embodiment of a sensornode that may be employed in the system of FIG. 1.

FIG. 2B illustrates another exemplary embodiment of a sensor node thatmay be employed in the system of FIG. 1.

FIG. 2C schematically illustrates an exemplary embodiment of acontroller node that may be employed in the system of FIG. 1.

FIGS. 3A-3B illustrate still another exemplary embodiment of a sensornode that may be employed in the system of FIG. 1.

FIG. 4 illustrates one embodiment of a process flow for activelymonitoring stormwater and providing stormwater data that is consistentwith the various embodiments presented herein.

FIG. 5 illustrates one embodiment of a process flow for configuringsensor nodes that is consistent with the various embodiments.

FIG. 6 illustrates one embodiment of a process flow for acquiring andaggregating stormwater data from stormwater sensor nodes that isconsistent with the various embodiments.

FIG. 7 illustrates one embodiment of a process flow for processing,analyzing, and reporting of stormwater data that is consistent with thevarious embodiments.

FIG. 8 is a block diagram of an example computing device in whichembodiments of the present disclosure may be employed.

DETAILED DESCRIPTION

Briefly stated, various embodiments are directed towards systems andmethods for the automatic monitoring and reporting of data relating tothe chemistry and flow of stormwater (i.e. stormwater data). Althoughthe various embodiments discussed herein are directed towardsmonitoring, analyzing, and reporting of data related to stormwater, itshould be understood that the monitored fluid is not limited tostormwater. That is, the various systems and methods disclosed mayreadily monitor various properties of any flowing liquid and/or gaseousfluid, including but not limited to stormwater, rainwater, and the like.Such monitored fluid properties include but are not otherwise limited tofluid volume, fluid flow rate, fluid turbidity, fluid pH-level, fluidviscosity, fluid temperature, fluid velocity, fluid depth, and the like.Virtually any property of any fluid, including the chemistry of thefluid, may be monitored and reported on via the various embodiments.

More specifically, multiple fluid sensors are exposed to stormwater viapositioning the sensors in locations of interest, e.g. within cavitiesof stormwater drainage systems. Locations of interest may includelocations where it is desirable to acquire data relating to the rainfalland/or stormwater flowing through the location. In various embodiments,fluid sensors are placed within the cavities or fluid flow paths (orchannels) of pipes, tunnels, gutters, and the like of stormwaterdrainage systems. The sensors may be enabled to acquire stormwater dataindicating any of the various fluid properties that are desired tomonitor. In embodiments, the various sensors may be integrated and/orembedded into a sensor array. The sensor array may be integrated and/orembed into a sensor device and exposed to fluid flowing through thestormwater drainage system.

A sensor device may be enabled to transmit its acquired stormwater data,either directly or indirectly, to one or more remote computing devices.In some embodiments, a sensor device is enabled to receive stormwaterdata from other sensor devices. Such a sensor device may repeat, route,and/or relay the stormwater data that is received from other sensordevices to other devices, such as but not limited to still other sensordevices and/or remote computing devices.

The sensor devices may be arranged into nodes of one or more networks ofsensors. Thus, a sensor device may be a sensor node. The networks may belocalized to specific areas, regions, and/or locations of interest. Insuch embodiments, a network of stormwater sensor devices may be referredto as a stormwater sensor localized-network (SSLN). A single SSLN mayinclude multiple sensor nodes distributed throughout the area and/orregion “covered” by the SSLN. There is virtually no upper bound to thetotal number of sensor nodes included in a single SSLN. An essentialfunctionality of a SSLN is that the SSLN is enabled to provide at leasta portion of the stormwater data acquired by at least a portion of itssensor nodes to one or more devices and/or nodes not included in theSSLN. Multiple SSLN may be arranged and/or constructed to coverunlimited, disparate, contiguous, and/or non-contiguous areas,locations, and/or regions of the planet.

For instance, in one non-limiting embodiment, a first SSLN is located toprovide stormwater-monitoring coverage across a first portion of amunicipal stormwater drainage system that services one region (e.g. aneighborhood) of the municipality. A second SSLN is located to providestormwater-monitoring coverage across a second portion of the drainagesystem that services a second region of the municipality. The first SSLNincludes a plurality of sensor nodes (e.g. 10 sensor nodes) that isstrategically distributed within the first portion of the stormwaterdrainage systems that services the first region. The second SSLN mayinclude another plurality of sensor nodes (e.g. 20 sensor nodes) that isstrategically distributed within the second portion of the stormwaterdrainage systems that services the second region. In some embodiments,an overlap (or intersection) exists for multiple SSLNs in the areas thatthe individual SSLN cover when acquiring stormwater and/or transmittingdata. In other embodiments, multiple SSLNs are distinct, and nointersection exists in the areas of coverage for multiple SSLNs.

multiple SSLN may provide at least some partial overlap in the coveragefor acquiring stormwater data. In other embodiments, the area for

A SSLN may include a controller node. In such embodiments, the sensornodes of a SSLN are enabled to transmit, either directly or indirectly,their acquired stormwater data to a controller node included in theSSLN. The controller node is enabled to aggregate the stormwater datafrom each of the sensor nodes and transmit the aggregated stormwaterdata to the one or more remote computing devices. Because the controllernode aggregates stormwater data from the plurality of nodes, thecontroller node may be a data-collection device. In other embodiments,at least a portion of the sensor nodes are enabled to transmit theiracquired stormwater data directly to one or more remote computingdevices and/or nodes of other SSLNs.

In various embodiments, a SSLN may employ a mesh network topology, i.e.an SSLN may be a mesh network. In such embodiments, at least a portionof the sensor nodes, in addition to acquiring stormwater data, may serveas a repeater, router, and/or relay data transmitting device fortransmitting the stormwater data acquired by other sensor nodes to thecontroller node of the SSLN. Various redundancies may be employed insuch mesh SSLNs. That is, self-healing techniques may be employed suchthat the loss of one or more sensor nodes in a particular SSLN does notdegrade the operation and/or functionality of the particular SSLN. SuchSSLNs may be referred to as self-healing SSLNs.

In some embodiments, a controller node of an SSLN is enabled to transmitstormwater data to a controller node of another SSLN. In this way, anetwork of SSLNs may be employed. Such SSLN may serve as a repeater,router, and/or relay data transmitting network, i.e. one SSLN may relay,route, and/or repeat the stormwater data acquired by another SSLN. Forinstance, a mesh network of SSLNs may be constructed. Again, variousself-healing techniques may be employed to enable a self-healing meshnetwork of self-healing mesh SSLNs.

One or more remote computing devices are enabled to receive stormwaterdata acquired by the sensor nodes of one or more SSLNs, from thecontroller nodes of the one or more SSLNs. Furthermore, such remotecomputing devices are enabled to register, configure, operate, andcontrol the deployed sensor nodes, as well as monitor, maintain, andoperate an unlimited number of SSLNs. A remote computing device isfurther enabled to automatically aggregate, process, and analyze thestormwater data from multiple SSLNs, as well as automatically generatevisualizations (i.e. plots, charts, graphs, and the like), reports, andother documents documenting the results of the acquisition and analysisof the stormwater data. The stormwater data, as well as the results ofthe stormwater data analysis and any documents documenting the resultsmay be automatically logged and/or stored on data storage devices. Suchlogged stormwater data and stormwater reports may be later retrieved forfurther analysis and/or review. The computing devices configuring andcontrolling the SSLNs, as well as the data storage devices storing thestormwater data and data analysis results may be distributed across astormwater monitoring system and/or platform. For instance, the servicesand/or functionalities of the stormwater monitoring system may beaccessed as cloud-based services and/or web-based services and/orfunctionalities.

Exemplary Stormwater Monitoring System

FIG. 1 illustrates an exemplary embodiment of a distributed system 100enabled to simultaneously and actively monitor stormwater, as well asother fluids, across multiple remote locations, areas, regions, and thelike that is consistent with the various embodiments discussed herein.Thus, distributed system 100 is a stormwater monitoring system. Morespecifically, system 100 acquires, aggregates, and analyzes stormwaterdata from the multiple remote locations, areas, regions, and the like.System 100 may log and/or archive the (analyzed and/or raw) stormwaterdata, as well as generate stormwater reports and notifications based onthe stormwater data analysis.

System 100 includes various user-computing devices, such as but notlimited to laptop 102, smartphone 104, desktop 106, tablet 108, and thelike. In other embodiments, system 100 may include more or lessuser-computing devices. For instance, system 100 may include additionalmobile devices, wearable devices, and the like. An exemplary, butnon-limiting embodiment of a computing device is discussed inconjunction with at least computing device 800 of FIG. 8. Howeverbriefly, a computing device may be referred to as a processor devicebecause a computing device generally employs and/or includes aprocessor. A generalized communication network, such as but not limitedto communication network 110, may communicatively couple at least aportion of user-computing devices 102-108.

Communication network 110 may be any communication network, includingvirtually any wired and or wireless communication technologies, wiredand/or wireless communication protocols, and the like. It should beunderstood that communication network 110 may be virtually anycommunication network that communicatively couples a plurality ofcomputing devices in such a way as to enable users of computing devicesto exchange information via the computing devices.

System 100 may include one or more storage devices, such as but notlimited to storage device 112. Storage device 112 may include volatileand non-volatile storage devices for digital data storage. Storagedevice 114 may include non-transitory storage media, such as but notlimited to magnetic and/or optical disks, magnetic tape, solid-statestorage media, and the like. Communication network 110 maycommunicatively couple storage device 112 to at least a portion ofuser-computing devices 102-108. In some embodiments, storage device 112may be a logical storage device logically distributed over multiplephysical storage devices. Thus, storage device 112 may be a virtualizedstorage device. For instance, one or more “cloud storage” servicesand/or service providers may provide, implement, and/or enable storagedevice 112.

Storage device 112 may store various data, including but not limited tosensor registration and configuration data 114, stormwater data 116, andstormwater reports 118. Storage device 112 may store machine-,processor-, and/or computer-executable instructions, such as but notlimited to instructions, that when executed, enabled the actions, steps,operations, or functionalities of various applications, such as but notlimited to stormwater monitoring application (SMA). Such SMAs include,but are not otherwise limited to server application (SMSA) 160,stormwater monitoring client application (SMCA) 180, standalonestormwater monitoring application (SSMA), and the like.

In some embodiments, a server-client architecture is employed. As shownin FIG. 1, desktop 106 is running and/or hosting SMSA 160 and tablet 108is running and/or hosting SMCA 180. Thus, desktop 106 may be aserver-computing device and tablet 108 may be a client-computing device.Other embodiments are not so constrained, and virtually any computingdevice may run and/or host either SMSA 160 and/or SMCA 180. In someembodiments, SMSA 160 may be run on a web-based and/or cloud-basedserver. Thus, the functionalities and/or services of system 100 may beaccessed via web-based and/or cloud-based services and/orfunctionalities.

In other embodiments, a server-client architecture is not employed. Thatis, the functionalities and operations of SMSA 160 and SMCA 180 may beintegrated and/or embedded within a single application, i.e. astandalone application. For instance, a single standalone application,such as but not limited to standalone stormwater monitoring application(SSMA) 190 may provide all of the functionalities associated with thecombination of SMSA 160 and SMCA 180. FIG. 1 shows laptop 102 hostingand/or running SSMA 190, although other embodiments are not soconstrained. Virtually any computing device may run, host, and/orexecute any of SMSA 160, SMCA 180, and/or SSMA 190.

Although FIG. 1 shows SMAs running on a single computing device, SMSA160, SMCA 180, SSMA 190, or any other application may be distributedacross multiple physical computing devices. In some embodiments, atleast a portion of such applications may be hosted and/or running on oneor more virtual machines (VMs), implemented by virtually any computingdevice, such as but not limited to user-computing devices 102-108.

System 100 includes one or more stormwater sensor localized-networks(SSLN). As shown in FIG. 1, system 100 includes two SSLNs: SSLN A 120and SSLN B 130. Other embodiments are not so constrained, i.e. otherembodiments may include fewer or more SSLNs than system 100. Each SSLNmay include at least one controller node and one or more sensor nodes.For instance, SSLN A 120 includes controller node 122 and six sensornodes, such as but not limited to sensor node 124. Similarly, SSLN B 130includes controller node 132 and six sensor nodes, such as but notlimited to sensor node 134.

There is no upper bound to the number of controller nodes and sensornodes included in a single SSLN. The number of controller nodes andsensor nodes may be scaled based on the number of stormwater measurementlocations and the required bandwidth for data transmission. Furthermore,embodiments of such a system may include fewer or more than two SSLN.There is no upper bound to the number of SSLNs that may be included insystem 100. Various embodiments of controller nodes are discussed inconjunction with at least controller node 270 of FIG. 2C.

Various embodiments of sensor nodes are discussed in conjunction with atleast sensor nodes 200, 250, and 300 if FIGS. 2A, 2B, and 3A-3Brespectively. However, briefly here, the sensor nodes may include aplurality of fluid sensors, such as but not limited fluid flow-ratesensors, temperature sensors, turbidity sensors, pH-level sensors, andthe like. The plurality of sensors may be embedded and/or integrated ina sensor array. The sensor nodes may be deployed in a remote location ofinterest to acquire stormwater data and/or measurements via the varioussensors within the sensor array. When deployed, the various fluidsensors may be configured to be exposed to stormwater other anotherfluid. The sensors sample the fluid and make measurements of the variousproperties of the fluid. When the fluid is flowing stormwater, the datagenerated via the sensors of the sensor nodes is referred to as“stormwater data.” The sensor nodes acquire stormwater data.

Each sensor node within a SSLN may wirelessly and/or viawired-communication transmit the acquired stormwater data to acontroller node (or to another sensor node) of the SSLN. The controllernode may aggregate the stormwater data from the plurality of sensornodes. Because the controller node aggregates stormwater data from theplurality of nodes, the controller node may be a data-collection device.The controller node may provide aggregated the stormwater data to a SMA,such as but not limited to SMSA 160, SMCA 180, SSMA 190, or the like,for stormwater data processing, analysis, visualization, storage, and/orreporting.

Turning the attention to the topologies of a SSLN and the communication(i.e. data/information transmission) inter and intra-SSLNs, as usedherein, “local-data transmission” refers to the transmission of anyinformation, including but not limited to stormwater data, sensor nodeconfigurations, and the acquisition/transmission frequencies a betweennodes (i.e. sensor and/or controller nodes) within a single SSLN.Accordingly, local-data transmission refers to the transmission ofinformation between the sensor nodes of a SSLN and/or between the sensornodes and one or more controller nodes of the SSLN. Local-datatransmission and/or local-communication channels are shown within SSLNA/B 120/130 via the hashed bi-directional communication arrows.

In contrast to local-data transmission, “remote-data transmission”refers to the transmission of any information from a (sensor and/orcontroller) node within a SSLN to a (sensor and/or controller) nodeoutside the SSLN and/or a computing device outside the SSLN and/or froma node/computing device outside the SSLN to a node within the SSLN.Remote-data transmission may refer to the transmission of informationand/or data between a sensor/controller node and communication network110. Remote-data transmission and/or remote-communication channels areshown between controller nodes 122/132 and communication network 110 viathe solid bi-directional communication arrows. In the variousembodiments, each SSLN is enabled for both local-data transmission andremote-data transmission.

In some embodiments, to enable remote-data transmissions betweenuser-computing devices and an SSLN, at least one of the one or morecontroller nodes in each SSLN is communicatively coupled to acommunication network 110, as shown in FIG. 1 (and indicated by theremote-data transmission solid bi-directional arrows between controllernodes 122/132 and communication network 110). Accordingly, to enableremote-data transmissions, each SSLN includes at least one controllernode that is communicatively coupled to at least one of SMSA 160, SMCA180, and/or SSMA 190, via communication network 110. As discussed inconjunction with at least controller node 270 of FIG. 2C, a controllernode may include one or more onboard data transmitter devices to enableremote-data transmission thru communication network 110. Such onboarddata transmitter devices may include remote-data transmitter devices.

Furthermore, to enable local-data transmission within a SSLN, eachsensor node in a SSLN is either directly and/or indirectlycommunicatively coupled to at least the controller node of the SSLN thatis communicatively coupled to communication network 110 (and indicatedby the local-data transmission hashed bi-directional arrows within SSLNA/B 120/130). As discussed in conjunction with at least sensor node 200of FIG. 2A, a sensor node may include one or more onboard datatransmitter devices to enable local-data transmission thru with othersensor nodes and one or more controller nodes. Such onboard datatransmitter devices may include local-data transmitter devices.

In various embodiments, in addition to the remote-data transmitterdevices, a controller node may include local-data transmitter devices toenable local-data transmission between a controller node and sensornodes of the SSLN (or other controller nodes of the SSLN). Thus, in thevarious embodiments, a controller node may employ remote-datatransmission devices to communicate with devices outside of its own SSLNand employ local-data transmission devices to communicate with nodeswithin its own SSLN.

Local-data transmission and remote-data transmission may be enabled viaseparate communication protocols and/or (wired and/or wireless)communication devices. For instance, remote-data transmission may employvarious internet protocols, such as but not limited to any of the commonTCP/IP protocols. Remote-data transmission devices may include virtuallyany communication devices, such as but not limited to WiFi-enableddevices, Ethernet-enabled devices, Bluetooth-enabled devices,USB-enabled devices, optical data transmission enabled-devices, and thelike. Local-data transmission devices may include virtually any (wiredand/or wireless) communication devices, such as but not limited toradio-frequency (RF) wireless transmission-enabled devices. It should beunderstood that wireless local-data transmission devices may employcommunication bands other than RF-bands. In some embodiments, local-datatransmission devices may be associated with smaller communication(spatial) ranges than corresponding remote-data transmission. Thus,local-data transmission may be referred to as “short-range” datatransmission and/or communication and remote-data transmission may bereferred to as “long-range” data transmission.

As discussed above, sensor nodes acquire stormwater data via variousembedded fluid sensors. The stormwater data from each sensor node isrelayed and/or routed (either directly or indirectly via one or moreother sensor nodes) to one or more controller nodes (via local-datatransmission). The controller nodes can then act as a communicationrelay, repeater, and/or router to provide the stormwater data to SMSA160, SMCA 180, and/or the SSMA 190 (via remote-data transmission). Asused herein, “indirect” data transmission between two nodes islocal-data transmission between two nodes of a SSLN when one or moreother nodes is “between” the two communication nodes and the one or moreother nodes acts as a transmission relay, router, and/or repeaterbetween the two communicating nodes. That is, the two communicatingnodes are “indirectly communicatively coupled.”

In contrast to indirect transmission and/or communication of data,“direct” data transmission is local-data transmission between two nodesof a SSLN with no other node in “between” the communicating nodes, i.e.the two communicating nodes are paired for communication. That is, thetwo communicating nodes are “directly communicatively coupled.”Local-data transmission may occur in broadcast mode.

In some embodiments, each sensor node is directly communicativelycoupled to a controller node. In other embodiments, one or more sensornodes are indirectly communicatively coupled to the controller node. Insuch embodiments, if not directly communicatively coupled to acontroller node, then a sensor node is indirectly communicativelycoupled to a controller node via other sensor nodes. That is, as shownin FIG. 1, sensor node 124 may serve as a data transmission relay,router, and/or repeater between a sensor node 126 and controller node122 of SSLN A 120. Note that sensor node 126 is indirectlycommunicatively coupled to controller node 122 and sensor node 124 isdirectly communicatively coupled to controller node 122. In the variousembodiments, each sensor node is directly communicatively coupled to atleast one other sensor node that is either indirectly (and/or directly)communicatively coupled to the controller node via one or more “hops”through other sensor nodes. Thus, in some embodiments, an SSLN may bearranged in a mesh network topology, i.e. an SSLN may be a mesh network.

In some embodiments, a mesh SSLN may be a “self-healing” communicationnetwork. That is, various mesh self-healing techniques, algorithms,network topologies may be employed to include various redundantcommunication routes to avoid the degradation of network performance inresponse to the loss of one or more nodes of the mesh network. Forinstance, the communicative coupling between the sensor nodes may besuch that the loss of a single sensor node will not isolate (datatransmission-wise) any other sensor node from a controller node that isenabled for remote-data transmission. As shown in FIG. 1, via thebi-directional local-data communication channels (hashed bi-directionalarrows), the loss of any single sensor node in either SSLN 120 and/orSSLN 130 will not isolate any sensor node from the correspondingcontroller node in the SSLN.

In some embodiments, the sensor nodes and/or the controller nodesinclude logic devices that actively monitor and manage networkperformance. The sensor and/or controller nodes may act as an activerouter that bases their routing of data transmission on a current stateof the self-healing mesh SSLN, i.e. which, if any sensor nodes haveceased operating.

By employing differing mesh network topologies and self-healingtechniques that employ differing levels of redundancy in thecommunicative coupling of the nodes, virtually any level ofdata-transmission redundancy may be achieved in a SSLN. That is, aself-healing mesh SSLN may lose up M sensor nodes without isolating anyother remaining sensor nodes from a controller node, where M is apositive integer that is less than integer N, the number of sensor nodesincluded in the SSLN. As shown in FIG. 1, in such self-healing meshnetwork topologies, each sensor node may be communicatively coupled totwo or more other sensor nodes and each controller node iscommunicatively coupled to two or more sensor nodes. The networktopology of a SSLN may include virtually any topology with the requiredlevel of local-data transmission redundancy for the particularapplication. Accordingly, a SSLN may include virtually any mesh networktopology.

Turning attention to the functionalities and operation of an SMA, inaddition to processing the stormwater data, an SMA may manage andmaintain each of the SSLNs that are acquiring and providing stormwaterdata. More specifically, one or more SMAs may be employed by a user toregister and configure each of the controller nodes and each of thesensor nodes of the SSLNs. Registering the sensor nodes and controllernodes may include storing a geo-location and a sensor identification foreach sensor node in sensor registration and configuration data 114 (oranother storage location). The geo-location and/or the sensoridentification may be manually provided by a user of the SMA and/orautomatically determined. For instance, onboard global positioningdevices may be included in the sensor/controller nodes. Furthermore, aunique identifier may be included in the sensor/controller nodes. Thesensor nodes may be automatically interrogated to determine suchregistration information.

In addition to registering the sensor nodes, the SMA may be employed toconfigure the sensor nodes and the controller nodes. The configurationof the controller and the sensor nodes may be stored in sensorregistration and configuration data 114. The configuration of a sensornode may include at least a data-acquisition frequency and a (sensornode) data-transmission frequency. The data-acquisition frequency may bethe frequency that a sensor nodes acquires stormwater data. Forinstance, the data-acquisition of a sensor node may be acquired dataonce and hour. Similarly, the configuration of a controller node mayinclude a (controller node) data-transmission frequency, that indicatesthe frequency that the aggregated stormwater data is provided to theSMA.

In addition to acquiring data at the data-acquisition frequency, asensor node may acquire stormwater data if one or more predeterminedflow-event thresholds are detected. That is, stormwater data may beacquired when a sensor of a sensor node detects a signal greater than athreshold level. In various embodiments, a sensor node may acquirestormwater data when a flow event is received at the sensor node. A flowevent may be received at the sensor node if it is time to acquirestormwater data (based on the data-acquisition frequency) or when one ormore flow-event thresholds are exceed.

The SMA may provide each sensor node its sensor node configuration viathe controller node. The controller node may then provide each sensornode its configuration via local-data transmission around the SSLN. Insome embodiments, a data-transmission pipeline is generated andmaintained by the SMW. A controller node may request the its sensor nodeconfiguration, as well as its sensor node configurations of other sensornodes. The controller node and sensor node configurations may beprovided to the controller node via the data-transmission pipeline.Furthermore, each of the sensor nodes may request its configuration fromthe controller node. For instance, a sensor node may be scheduled toperiodically inquire regarding its configurations. In response to therequest, the controller node may answer by providing the sensor node itssensor node configuration via the mesh network topology. Upon receivingthe response from a controller node, the sensor node may update itslocal configuration and/or settings.

A sensor node may continue to acquire stormwater data for each flowevent. At the end of each data-transmission cycle, a sensor node maytransmit the acquired stormwater data to the controller node via themesh network. In various embodiments, a plurality of flow events mayoccur between data-transmission cycles, i.e. a sensor node may bufferstormwater data. The sensor node may package and transmit the stormwaterdata in data packets to the controller node.

The controller aggregates the stormwater data packets from each of thesensor nodes. In addition to stormwater data, the data packets mayinclude the associated sensor nodes identification, timestamp,geo-location, or any other metadata associated with the measurement ofthe stormwater's various properties. The aggregated stormwater data maybe buffered and/or temporally stored by the controller node. At the endof a data-transmission cycle of the controller node, the controller nodemay transmit the stormwater data to the SMA. Note that thedata-transmission frequency of the controller node may be different thanthe data-transmission frequency of the sensor nodes. In someembodiments, the controller node provides the aggregated stormwater datato the SMA in response to a data request from the SMA.

The SMA may enable the storing or archiving of the stormwater datapackets. For instance, the stormwater data packets may be stored instormwater data 116 of FIG. 1. The SMA may aggregate the stormwater dataover multiple data-transmission cycles. For instance, the SMA mayaggregate stormwater data over several days, weeks, or virtually anytemporal period. The SMA may aggregate stormwater data from multipleSSLNs.

In various embodiments, the SMA may process and analyze the aggregatedstormwater data. For instance, the SMA may normalize the stormwaterdata, as well as calibrate the stormwater data. In various embodiments,the SMAA may determine various stormwater metric based on the normalizedand calibrated data. For instance, the SMA may determine aGauckler-Manning coefficient for the stormwater drainage system based onthe stormwater data. For instance, the Gauckler-Manning formula, shownbelow may be employed to determine the Gauckler-Manning coefficient (n).

${V = {\frac{k}{n}R_{h}^{2/3}S^{1/2}}},$

where V is the cross-sectional average velocity of the flowingstormwater, Rh is the hydraulic radius, S is the slope of the hydraulicgrade line (i.e. channel bed slope when the water depth is constant),and k is a conversion factor.

For each SSLN, the SMA may combine the corresponding stormwater metricsto generate one or more site-level stormwater measurements. A site-levelstormwater measurement may correspond to stormwater measurements for thesit covered by the SSLN. For instance, the stormwater metrics may becombined to generate a site-level average flow rate, average flowvolume, or the like.

The SMA may actively monitor one or more stormwater trigger conditions.A user notification may be provided to a user if a stormwater conditionis triggered. For instance, if a pH-level of the stormwater exceeds aspH-threshold, based on the stormwater data, the SMA may provide anotification to a user. The SMA may automatically generatevisualizations (i.e. plots, charts, graphs, and the like) of thesite-level storm measurements. A display device of a user-computingdevice may be employed to display such visualizations. An SMA mayautomatically generate stormwater reports, and other documentsdocumenting the results of the acquisition and analysis of thestormwater data, including the stormwater site-level measurements. Suchstormwater reports may be stored in stormwater reports 118 of FIG. 1.

Sensor and Controller Nodes of Stormwater Sensor Localized Networks

FIG. 2A schematically illustrates an exemplary embodiment of remotesensor node 200 that may be employed in the system 100 of FIG. 1. Sensornode 200 may be a fluid sensor node. In some embodiments, sensor node200 is a stormwater sensor node. That is, sensor node 200 may beemployed as a sensor node within a stormwater sensor localized-network(SSLN), such as but not limited to SSLN A 120 and/or SSLN B 130 ofFIG. 1. For instance, fluid sensor node 200 may be employed as any ofsensor nodes 124, 126, and/or 134.

Sensor node 200 may be exposed to stormwater 202 or any other liquid orgaseous fluid. Sensor node may include a fluid inlet 242, a fluid outlet244, and a fluid flow channel 240 between the fluid inlet 242 and thefluid outlet 244. Sensor node 200 may include a sensor array 210 thatexposes one or more fluid sensors to fluid flowing in fluid flow channel240. Such fluid sensors included in sensor array 210 may include but arenot limited to fluid flow-rate sensors, temperature sensors, turbiditysensors, pH-level sensors, and the like. The various sensors may sensevarious properties of the fluid flowing through fluid flow channel 240.

Sensor node 200 may include onboard power sources 212, such as but notlimited to rechargeable and/or replaceable batteries to provide DCand/or AC (in combination with a power inverter) power to the variousother components, devices, and sensors of sensor node 200. Sensor node200 may include one or more onboard logic devices. Such logic devicesinclude, but are not otherwise limited to microprocessors,microcontrollers, central processing units (CPUs), field programmablegate arrays (FPGAs), application specific integrated circuits (ASICs),systems-on-a-chip (SOC), and the like. Such logic devices may performthe operations and/steps that control the sensors, as well as othercomponents and devices included in sensor node 200. In some embodiments,the logic devices may perform data transmission routing operations.

Sensor node 200 may additionally include various onboard volatile and/ornon-volatile machine-readable data storage devices 234 to at leasttemporally store, buffer, and/or cache data, such as but not limited todata generated via sensor array 210. Such data storage devices include,but are not otherwise limited to SRAM devices, (S)DRAM devices, EEPROMdevices, FLASH devices, and the like. Sensor node 200 may include one ormore onboard global positioning devices 236. Such global positioningdevices 236 may include global positioning satellite (GPS) receivers todetermine the geo-coordinates of a geo-location of sensor node 200.

Sensor node 200 may also include onboard data transmitter devices 238 toprovide and receive (i.e. transmits) information, such as but notlimited to stormwater data. Data transmitter devices 238 may enable datatransmission. For instance, onboard transmitter devices 238 includeslocal-data transmitter devices 246, which enables local-datatransmission within a SSLN. For instance, local-data transmitter devices246 may include radio-frequency (RF) data-transmission devices. Notethat each of these devices, components, sensors, power sources, and thelike included in sensor node 200 may be coupled via the generalized bus230. Bus 230 may include communication and/or power busses.

FIG. 2B illustrates another exemplary embodiment of a sensor node 250that may be employed in the system 100 of FIG. 1. Sensor node 250 may beemployed as a sensor node within a stormwater sensor localized-network(SSLN), such as but not limited to SSLN A 120 and/or SSLN B 130 ofFIG. 1. As such, sensor node 250 may include similar features,components, devices, sensors, and the like of sensor node 200 of FIG.2A. Thus, sensor node 250 may be employed in a stormwater sensorlocalized-network (SSLN), such as but not limited to SSLN A 120 and/orSSLN B 130 of FIG. 1. Sensor node 250 includes a housing 252 that housesthe various components, sensors, devices, and communication/power busesof sensor node 250. Sensor node 250 includes inlet-fluid cover 264 thatcovers fluid inlet 254. Sensor node 250 also includes fluid-outlet cover266 that covers fluid outlet 262. Fluid flow channel 258 enables fluidcommunication between fluid inlet 254 and fluid outlet 262, i.e. fluid260 may flow between fluid inlet 254 and fluid outlet 262. Fluid-inletcover 264 and fluid-outlet cover 266 may include one or more screens,mesh, and/or filters that may keep fluid flow channel 258 free of debrisand/or sediment that cannot pass through fluid-inlet cover 264 and/orfluid-outlet cover 266.

Fluid 260 within fluid flow channel 258 is exposed to the varioussensors included in sensor array 262. At least a portion of theelectronic components and/or devices, such as but not limited to powersources, logic devices, data storage devices, global positioningdevices, and data transmitter devices may be included and/or integratedwith circuit board 256. That is, circuit board 256 may be populated withvarious electronic devices included with sensor array 250.

FIG. 2C schematically illustrates an exemplary embodiment of acontroller node 270 that may be employed in the system 100 of FIG. 1.Controller node 270 may be employed as a controller node within astormwater sensor localized-network, such as but not limited to SSLN A120 and/or SSLN B 130 of FIG. 1. For instance, controller node 270 maybe employed as any of controller nodes 122 and/or 132. In someembodiments, controller node 270 may be a data-collection device.

Controller node 270 may include onboard power sources 272, such as butnot limited to rechargeable and/or replaceable batteries to provide ACand/or DC power to the various other components, devices, and sensors ofsensor node 200. Onboard power sources 272 may include AC ports toprovide AC power. Controller node 270 may include one or more onboardlogic devices. Such logic devices include, but are not otherwise limitedto microprocessors, microcontrollers, central processing units (CPUs),field programmable gate arrays (FPGAs), application specific integratedcircuits (ASICs), systems-on-a-chip (SOC), and the like. In someembodiments, the logic devices may perform data transmission routingoperations.

Controller node 270 may additionally include various onboard volatileand/or non-volatile machine-readable data storage devices 376 to atleast temporally store, buffer, and/or cache data, such as but notlimited to storm water. Such data storage devices include, but are nototherwise limited to SRAM devices, (S)DRAM devices, EEPROM devices,FLASH devices, and the like. Controller node 270 may include one or moreonboard global positioning devices 278. Such global positioning devices278 may include global positioning satellite (GPS) receivers todetermine the geo-coordinates of a geo-location of controller node 270.

Controller node 270 may also include onboard data transmitter devices280 to transmit and receive information, such as but not limited tostormwater data. Data transmitter devices 280 may enable datatransmission. For instance, onboard transmitter devices 280 includeslocal-data transmitter devices 246, which enables local-datatransmission within a SSLN, and remote-data transmitter devices 282,which enables remote-data transmission to outside the SSLN. Forinstance, local-data transmitter devices 246 may include radio-frequency(RF) data-transmission devices. In various embodiments, remote-datatransmission devices may include various WiFi-enabled devices, Bluetoothenabled devices, Ethernet-enabled devices, or the like, Note that eachof these devices, components, sensors, power sources, and the likeincluded in controller node 270 may be coupled via the generalized bus290. Bus 290 may include communication and/or power busses.

FIGS. 3A-3B illustrate still another exemplary embodiment of a sensornode 300 that may be employed in the system of FIG. 1. FIG. 3A shows anoff-axis view of the sensor node 300 within a stormwater pipe, withstormwater flowing through the Sensor node 300 may include acompressions ring 330 that is inserted into the cavity of a stormwaterpipe. FIGS. 3A-3B illustrate still another exemplary embodiment of asensor node that may be employed in the system of FIG. 1. FIG. 3B showsa lateral cross-sectional view of sensor node 300 within the cavity ofthe stormwater pipe. Compression ring 330 holds the sensor node 300 inplace with an outward force exerted on the inner walls of the stormwaterpipe

Sensor node 300 may include a fluid temperature sensor 310 the acquirestormwater data relating to the temperature of the stormwater. Sensornode 300 may include an ultrasonic Doppler signal sensor 320 to acquiredata regarding the velocity of the slowing stormwater. Sensor node 300may include a pH-level sensor 312 to acquire data regarding the pH-levelof the stormwater.

Sensor node 300 may include a ultrasonic depth sensor 340 to acquirestorm data regarding the stormwater depth. Housing 350 may house othervarious electronic components, such as but not limited other sensors,onboard power sources (e.g. rechargeable batteries) onboard logicdevices, onboard data storage devices, onboard global positioningdevices, onboard data transmitter devices, and the like.

Generalized Processes for a Stormwater Monitoring and Reporting System

Processes 400-700 of FIGS. 4-7 will now be discussed. Briefly, processes400-700 may be employed to simultaneously and actively monitorstormwater, as well as other fluids, across multiple remote locations,areas, regions, and the like that is consistent with the variousembodiments discussed herein. Such processes may be implemented,executed, or otherwise performed via a single and/or a combination ofthe various embodiments discussed herein. System 100 of FIG. 1 mayenable such processes. In various embodiments, computing devices, suchas but not limited to user-computing device 102-108 of FIG. 1, orcomputing device 800 of FIG. 8, are enabled to carry out at leastportions of processes 400-700. In some embodiments, a stormwatermonitoring application (SMA), such as any of those shown in FIG. 1 mayenable at least portions of processes 400-700.

FIG. 4 illustrates one embodiment of a process flow for activelymonitoring stormwater and providing stormwater data that is consistentwith the various embodiments presented herein. Process 400 begins, aftera start block, at block 402 where a plurality of stormwater sensor nodesare registered. The sensor nodes may be included in a stormwater sensorlocalized network (SSLN). At noted throughout, the SSLN may beconfigured in a self-healing mesh network topology. Each of the sensornodes included in SSLN A 120 of FIG. 1 may be registered at block 402.The sensor nodes of the SSLN may be distributed across at least aportion of a stormwater drainage system.

In various embodiments, the location of each sensor node may beregistered at block 402. In some embodiments, a user may employ auser-computing device that is hosting and/or executing a SMA, such asbut not limited to SMSA 160, SMCA 180, and/or SSMA 190 of FIG. 1, toprovide the locations of the sensor nodes. The locations of each sensornode may include the geo-location of the sensor node in any geographiccoordinate system, i.e. the geo-coordinates. In at least one embodiment,the geo-location of at least a portion of the sensor nodes isautomatically determined via onboard positioning devices included in thesensor nodes.

The location of each sensor node may be stored. For instance, the sensornode geo-locations may be stored, logged, and/or archived in sensorregistration and configuration data 114 of storage device 112 of FIG. 1.The user may employ the SMA to associate and register a unique sensornode identification with the geo-location. In some embodiments,registering and associating the sensor node identification with thegeo-location of the sensor node via an interrogation of the sensor node.For instance, a media access control (MAC) address or some other uniqueidentifier of the sensor node may be determined automatically via aninterrogation of the sensor node. The geo-location and the associatedsensor node identifications may be registered in a database stored insensor registration and configuration data 114.

At block 404, the registered stormwater sensor nodes may be configured.Various embodiments of configuring stormwater sensor nodes are discussedin conjunction with at least process 500 of FIG. 5. However, brieflyhere, a user may employ a user-computing device to provide a sensorconfiguration for each of the sensor nodes. A sensor node configurationmay include data-acquisition frequencies and data-transmissionfrequencies. The sensor configuration may be provided to a controllernode of the SSLN. The controller node may provide the correspondingsensor configuration to each of the sensor nodes. In some embodiments, acontroller node configuration is also provided to the controller node atblock 404.

At block 406, each of the sensor nodes may be employed to acquirestormwater data. At block 408, the stormwater data from each of thesensor nodes may be aggregated at the controller node of the SSLN.Because the controller node aggregates stormwater data from theplurality of nodes, the controller node may be a data-collection device.At block 410, the aggregated stormwater data is periodically providedand/or transmitted to the user-computing device. Various embodiments ofacquiring stormwater data, aggregating the stormwater data, andtransmitting the stormwater data to the user-computing device arediscussed in conjunction with at least process 600 of FIG. 6.

At decision block 412, it is determined whether to continue to acquirestormwater data. If stormwater data acquisition is to be continued,process 400 returns to block 406 to acquire additional stormwater data.Otherwise, process 400 flows to block 414.

At block 414, user-computing device is employed to process and analyzethe stormwater data. Various embodiments for processing and analyzingthe stormwater data are discussed in conjunction with at least process700 of FIG. 7. However briefly here, the stormwater data may benormalized and calibrated at the user-computing device. Variousstormwater measurements may be determined at block 414. For instance,the Gauckler-Manning coefficient of the stormwater drainage system maybe determined. At block 416, the analyzed stormwater data may beprovided. Various embodiments of providing the analyzed stormwater dataare also discussed in conjunction with FIG. 7. Process 400 may terminateupon completion of 416.

FIG. 5 illustrates one embodiment of a process flow for configuringsensor nodes that is consistent with the various embodiments. Process500 begins, after a start block, at block 502, where stormdata-acquisition frequencies and stormwater data-transmissionfrequencies are received at the user-computing device. For instance, theuser may employ a stormwater monitoring application (SMA), such as butnot limited to SMSA 160, SMCA 180, and/or SSMA 190 of FIG. 1, to providethe frequencies. Briefly, the sensor configuration for each sensor nodemay include a stormwater data-acquisition frequency and adata-transmission frequency. The sensor node may acquire (i.e. sample)stormwater data at the data-acquisition frequency. The sensor node maybuffer and transmit the acquired stormwater data to the controller nodeat the data-transmission frequency of the sensor node configuration.

At block 504, the sensor node registrations are updated based on thestormwater data-acquisition and data-transmission frequencies. That is,the registrations of block 402 of FIG. 4 may be updated to include thevarious sensor configurations of the sensor nodes. The controller noderegistration may also be updated at block 402 to include theconfiguration of the controller node. The sensor and/or controller nodeupdated registrations may be stored at the storage device 112 of FIG. 1

At block 506, a data pipeline may be updated to push, transmit, and/orotherwise provide the sensor configurations (including thedata-acquisition and data-transmission frequencies) to the controllernode of the SSLN. The pipeline may be updated to also provide thecontroller node configuration to the controller node. The pipeline maybe enabled, managed, or other maintained by the SMA. At block 508, arequest for the data-acquisition and data-transmission frequencies maybe received. For instance, the controller node of the SSLN may bescheduled to request the sensor configurations for the sensor node fromthe SMA. Thus, the request received at block 508 may include a requestfrom the controller node (to the SMA) for the sensor configurations. Atblock 510, the sensor configurations (including the data-acquisition anddata-transmission frequencies) are provided to the controller node. Atblock 510, the controller node configuration may also be provided to thecontroller node

At block 512, the controller node settings may be updated based on thedata-acquisition and data-transmission frequencies, as well as othersettings, parameters, and the like of the sensor configurations. Forinstance, the settings of the controller node may be updated so that thecontroller node expects to receive stormwater data from each of thesensor nodes at the data-transmission frequencies of the stormwaternodes. The controller node may also be set to transmit the stormwaterdata to the SMA at the same (or separate) data-transmission frequency asthe sensor nodes transmit the data to the controller node.

At block 514, a request from each of the sensor nodes may be received.The request from a sensor node may be a request for its sensorconfiguration, including the data-acquisition and data-transmissionfrequencies. At block 516, at least the corresponding data-acquisitionand data-transmission frequencies are provided to each of the sensornodes. Other configuration parameters may be provided to the sensornodes at block 516. The mesh network topology of the SSLN may beemployed to provide the sensor configuration to the sensor nodes atblock 516.

At block 518, the settings of the sensor nodes are updated based on thesensor configuration. For instance, the settings of a sensor node mayupdate based on the data-acquisition, data-transmission frequencies, orother configurations of the sensor node. That is to say the sensor nodemay be configured at block 518. Process 500 may terminate uponcompletion of block 518.

FIG. 6 illustrates one embodiment of a process flow for acquiring andaggregating stormwater data from stormwater sensor nodes that isconsistent with the various embodiments. Process 600 begins, at decisionblock 602, where it is determined whether a fluid-flow event is receivedat a sensor node. A fluid flow event may be triggered at a sensor nodevia the detection of fluid flowing at a rate and/or volume that isgreater than a predetermined flow-event threshold.

A fluid flow event may be alternatively triggered via the end ofdata-acquisition cycle, where the period of the data-acquisition cycleis based on the data-acquisition frequency. For instance, at discussedin conjunction with at least process 500 of FIG. 5, the sensor nodeconfiguration may include a data-acquisition frequency. For instance,the data-acquisition frequency may be 1 data-acquisition/hr. Thus, theat decision block 602, a flow event may receive based on the detectionof fluid flowing and/or a data-acquisition frequency. In suchembodiments, the sensor node may acquire data once an hour, until theflow of a fluid is detected greater than the flow-event threshold. Insuch an event, the sensor node may acquire stormwater data at greaterfrequency than the data-acquisition frequency. If a flow event at thesensor node is received, process 600 flows to 604 to acquire stormwaterdata. Otherwise, process 600 returns to decision block 602 to wait for aflow event.

At block 604, the sensor node is employed to acquire stormwater data. Atleast a portion of the sensors included in a sensor may acquirestormwater data. For instance, stormwater data may include fluid datarelating to any of fluid volume, fluid flow rate, fluid turbidity, fluidpH-level, fluid viscosity, fluid temperature, fluid velocity, fluiddepth, and the like. The stormwater data may be acquired based on thesensor node configuration, i.e. once an hour or any otherdata-acquisition frequency.

At block 606, the stormwater data is provided to the controller node,via the network topology of the SSLN. The stormwater data may beprovided to the controller node at a rate based on the data-transmissionfrequency, i.e. the sensor nodes may transmit or otherwise prove theacquired stormwater data at a rate that is consistent with thedata-transmission frequency. Each sensor may provide its acquiredstormwater data to the controller node via a plurality of stormwaterdata packets. The data packets may include various metadata, such as butnot limited to the sensor node identification. At block 608, thestormwater data is aggregated at the controller node, i.e. thestormwater data packets for each of the sensor nodes may be aggregatedat the controller node. Because the controller node aggregatesstormwater data from the plurality of nodes, the controller node may bea data-collection device. The stormwater data may be aggregated fromeach of the sensor nodes of the SSLN.

At block 610, the aggregated stormwater data is provided to theuser-computing device based on the data-transmission frequency of thecontroller node. Thus, at block 610, the stormwater data packets may beprovided to the user-computing device. A communication network, such asbut not limited to communication network 110 of FIG. 1 may be employedto provide the user-computing device the stormwater data. In variousembodiments, the stormwater data is provided to a SMA that is hostedand/or executed by the user-computing device. Note that thedata-transmission frequency of the controller node may be separate thanthe data-transmission frequency of the sensor nodes.

At decision block 612, it is determined whether an additional flow eventis received. If an additional flow event (either triggered by the flowof fluid and/or the data-acquisition frequency of the sensor nodes) isreceived at a sensor node, process 600 returns to block 604 to acquireadditional stormwater data. Otherwise, process 600 flows to decisionblock 614. At decision block 614, it is determined whether to terminatestormwater data acquisition. If data acquisition is not to beterminated, process 600 returns to decision block 602 to wait foranother flow event. Otherwise, process 600 may be terminated.

FIG. 7 illustrates one embodiment of a process flow for processing,analyzing, and reporting of stormwater data that is consistent with thevarious embodiments. Process 700 starts, after a start block, at block702 where storm water data packets are stored. For instance storm waterdata packets may be received from the controller node. The storm waterdata packets may be stored in a storage device, such as but not limitedto storage device 112 of FIG. 1. Accordingly, the storm water data maybe logged and/or archived at block 702.

At block 704, the storm water data is normalized. The storm water datamay also be calibrated at block 704. At block 706 one or more stormwater metrics may be generated based on the normalized calibratedstormwater data. For instance various storm water metrics may be derivedfrom the calibrated stormwater data. The SMA may determine aGauckler-Manning coefficient for the stormwater drainage system based onthe stormwater metrics.

At block 410, site-level measurements may be generated based on thestormwater metrics. For each SSLN, the SMA may combine the correspondingstormwater metrics to generate one or more site-level stormwatermeasurements. A site-level stormwater measurement may correspond tostormwater measurements for the sit covered by the SSLN. For instance,the stormwater metrics may be combined to generate a site-level averageflow rate, average flow volume, or the like.

At decision block 710, it is determined whether to a stormwatercondition is triggered based on the site-level measurements. If astormwater condition is triggered, process 700 flows to block 712.Otherwise process 700 may flows to block 714. At block 712, one or morestormwater condition notifications may be provided to a user of the SMAbased on the triggers. For instance, is a stormwater flow velocity ofthe stormwater exceeds a flow-velocity threshold, based on thestormwater data, the SMA may provide a notification to a user.

At block 714, visualizations of the site-level stormwater measurementsmay be provided to the user of the SMA. For instance, a displace deviceof the user-computing device may be employed to display various plots,charts, graphs, and the like, based on the stormwater metrics. At block716, one or more stormwater reports may be generated based on thesite-level stormwater measurements and/or the stormwater metrics. Thestormwater reports may be stored in the data storage device of FIG. 1.Process 700 may terminate after execution of block 716.

Illustrative Computing Device

Having described embodiments of the present invention, an exampleoperating environment in which embodiments of the present invention maybe implemented is described below in order to provide a general contextfor various aspects of the present invention. Referring to FIG. 8, anillustrative operating environment for implementing embodiments of thepresent invention is shown and designated generally as computing device800. Computing device 800 is but one example of a suitable computingenvironment and is not intended to suggest any limitation as to thescope of use or functionality of the invention. Neither should thecomputing device 800 be interpreted as having any dependency orrequirement relating to any one or combination of componentsillustrated.

Embodiments of the invention may be described in the general context ofcomputer code or machine-useable instructions, includingcomputer-executable instructions such as program modules, being executedby a computer or other machine, such as a smartphone or other handhelddevice. Generally, program modules, or engines, including routines,programs, objects, components, data structures, etc., refer to code thatperform particular tasks or implement particular abstract data types.Embodiments of the invention may be practiced in a variety of systemconfigurations, including hand-held devices, consumer electronics,general-purpose computers, more specialized computing devices, etc.Embodiments of the invention may also be practiced in distributedcomputing environments where tasks are performed by remote-processingdevices that are linked through a communications network.

With reference to FIG. 8, computing device 800 includes a bus 810 thatdirectly or indirectly couples the following devices: memory 812, one ormore processors 814, one or more presentation components 816,input/output ports 818, input/output components 820, and an illustrativepower supply 822. Bus 810 represents what may be one or more busses(such as an address bus, data bus, or combination thereof). Although thevarious blocks of FIG. 8 are shown with clearly delineated lines for thesake of clarity, in reality, such delineations are not so clear andthese lines may overlap. For example, one may consider a presentationcomponent such as a display device to be an I/O component, as well.Also, processors generally have memory in the form of cache. Werecognize that such is the nature of the art, and reiterate that thediagram of FIG. 8 is merely illustrative of an example computing devicethat can be used in connection with one or more embodiments of thepresent disclosure. Distinction is not made between such categories as“workstation,” “server,” “laptop,” “hand-held device,” etc., as all arecontemplated within the scope of FIG. 8 and reference to “computingdevice.”

Computing device 800 typically includes a variety of computer-readablemedia. Computer-readable media can be any available media that can beaccessed by computing device 800 and includes both volatile andnonvolatile media, removable and non-removable media. By way of example,and not limitation, computer-readable media may comprise computerstorage media and communication media.

Computer storage media include volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer-readable instructions, data structures,program modules or other data. Computer storage media includes, but isnot limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other optical diskstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, or any other medium which can be used tostore the desired information and which can be accessed by computingdevice 800. Computer storage media excludes signals per se.

Communication media typically embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism and includesany information delivery media. The term “modulated data signal” means asignal that has one or more of its characteristics set or changed insuch a manner as to encode information in the signal. By way of example,and not limitation, communication media includes wired media such as awired network or direct-wired connection, and wireless media such asacoustic, RF, infrared and other wireless media. Combinations of any ofthe above should also be included within the scope of computer-readablemedia.

Memory 812 includes computer storage media in the form of volatileand/or nonvolatile memory. Memory 812 may be non-transitory memory. Asdepicted, memory 812 includes instructions 824. Instructions 824, whenexecuted by processor(s) 814 are configured to cause the computingdevice to perform any of the operations described herein, in referenceto the above discussed figures, or to implement any program modulesdescribed herein. The memory may be removable, non-removable, or acombination thereof. Illustrative hardware devices include solid-statememory, hard drives, optical-disc drives, etc. Computing device 800includes one or more processors that read data from various entitiessuch as memory 812 or I/O components 820. Presentation component(s) 816present data indications to a user or other device. Illustrativepresentation components include a display device, speaker, printingcomponent, vibrating component, etc.

I/O ports 818 allow computing device 800 to be logically coupled toother devices including I/O components 820, some of which may be builtin. Illustrative components include a microphone, joystick, game pad,satellite dish, scanner, printer, wireless device, etc.

Embodiments presented herein have been described in relation toparticular embodiments which are intended in all respects to beillustrative rather than restrictive. Alternative embodiments willbecome apparent to those of ordinary skill in the art to which thepresent disclosure pertains without departing from its scope.

From the foregoing, it will be seen that this disclosure in one welladapted to attain all the ends and objects hereinabove set forthtogether with other advantages which are obvious and which are inherentto the structure.

It will be understood that certain features and sub-combinations are ofutility and may be employed without reference to other features orsub-combinations. This is contemplated by and is within the scope of theclaims.

In the preceding detailed description, reference is made to theaccompanying drawings which form a part hereof wherein like numeralsdesignate like parts throughout, and in which is shown, by way ofillustration, embodiments that may be practiced. It is to be understoodthat other embodiments may be utilized and structural or logical changesmay be made without departing from the scope of the present disclosure.Therefore, the preceding detailed description is not to be taken in alimiting sense, and the scope of embodiments is defined by the appendedclaims and their equivalents.

Various aspects of the illustrative embodiments have been describedusing terms commonly employed by those skilled in the art to convey thesubstance of their work to others skilled in the art. However, it willbe apparent to those skilled in the art that alternate embodiments maybe practiced with only some of the described aspects. For purposes ofexplanation, specific numbers, materials, and configurations are setforth in order to provide a thorough understanding of the illustrativeembodiments. However, it will be apparent to one skilled in the art thatalternate embodiments may be practiced without the specific details. Inother instances, well-known features have been omitted or simplified inorder not to obscure the illustrative embodiments.

Various operations have been described as multiple discrete operations,in turn, in a manner that is most helpful in understanding theillustrative embodiments; however, the order of description should notbe construed as to imply that these operations are necessarily orderdependent. In particular, these operations need not be performed in theorder of presentation. Further, descriptions of operations as separateoperations should not be construed as requiring that the operations benecessarily performed independently and/or by separate entities.Descriptions of entities and/or modules as separate modules shouldlikewise not be construed as requiring that the modules be separateand/or perform separate operations. In various embodiments, illustratedand/or described operations, entities, data, and/or modules may bemerged, broken into further sub-parts, and/or omitted.

The phrase “in one embodiment” or “in an embodiment” is used repeatedly.The phrase generally does not refer to the same embodiment; however, itmay. The terms “comprising,” “having,” and “including” are synonymous,unless the context dictates otherwise. The phrase “A/B” means “A or B.”The phrase “A and/or B” means “(A), (B), or (A and B).” The phrase “atleast one of A, B and C” means “(A), (B), (C), (A and B), (A and C), (Band C) or (A, B and C).”

What is claimed is:
 1. A computer-readable non-transitory storage mediumhaving instructions stored thereon for monitoring fluid, which, whenexecuted by a processor device cause the processor device to performactions comprising: providing, by a data-collection device, a portion ofa configuration to each of a plurality of fluid sensor devices, whereinthe configuration includes at least a data-acquisition frequency and adata-transmission frequency, the portion of the configuration at leastincludes the data-acquisition frequency; in response to receiving theportion of the configuration from the data-collection device, updatingsettings of the plurality of fluid sensor devices such that each of theplurality of fluid sensor devices is configured to acquire fluid databased on the received data-acquisition frequency; acquiring, by each ofthe plurality of fluid sensor devices, the fluid data based on theupdated settings, wherein the settings are updated based on at least thereceived data-acquisition frequency; aggregating, by the data-collectiondevice, the fluid data acquired from each of the plurality of fluidsensor devices; and periodically providing, by the data-collectiondevice, the aggregated fluid data to a user-computing device based onthe data-transmission frequency.